Related Topics
Pharos Designer imposes the following project limits which can not be exceeded:
| Groups | 1024 | |
| Fixtures | 30000 | Discrete or compound fixtures |
| Fixture elements | 60000 | Elements or pixels within compound fixtures eg. 18 per James Thomas Pixeline 1044 |
| Moving lights | 200 | Automated or moving lights and conventional fixtures with scrollers |
| Pixel matrices | 256 | |
| Frame arrays | 1000 | Instances of media, perlin noise, starfield, text and custom presets deployed on timelines |
| Timelines | 500 | |
| AVC presets | 256 | |
| Custom presets | 256 | |
| Media presets | 256 | Imported media clips |
| Media slots | 1024 | |
| Text slots | 1024 | |
| Fonts | 16 | |
| Mover presets | 256 | |
| Triggers | 1024 | |
| Conditions per trigger | 32 | |
| Actions per trigger | 32 | |
| Controllers | 40 | So if all LPC 2s then the maximum number of DMX universes in the project is 80 (80 x 512 = 49960 DMX 512 channels) |
| Remote Devices (excluding RIO D) | 100 | Per Remote Device type per Designer project. If you are planning to use more that 16 of one or more remote devices please contact support to discuss your requirements in advance. |
| DALI and RIO Ds | Please see DALI Interfaces for DALI and RIO D limitations | |
| KiNet power supplies | 1024 | Per Controller in a Designer project |
| Timecode Buses | 6 | MIDI or linear (SMPTE/EBU) timecode sources |
| Network Buses | 5 | Ethernet trigger sources eg. UDP |
| Audio Buses | 4 | Audio trigger sources |
| Plan size (pixels) | 8192x8192 | Plan and fixture library scale is 1cm:1pixel (0.394":1pixel) |
As you can see from the above limits, the Pharos control system can scale to an impressive size that rivals even state-of-the-art lighting consoles.
However, while the Controllers themselves provide a scalable solution (each Controller only stores and processes the data relevant to it), the PC running the Designer software will need greater performance, particularly the OpenGL graphics system, as the project size increases. For very large projects, or projects where some of the above limitations are restrictive, please contact support to discuss your requirements in advance.
Just like any other computational device, Controllers have a finite amount of resources available to them.
The Pharos system is designed to spread the load across all Controllers in a project. You can aid this by patching fixtures as evenly as possible across all Controllers.
As well as lighting playback, Controllers are often used as interfaces to a wider system. This was intentional and is why the system is so flexible but bear in mind that if a Controller is being asked to deal with a substantial amount of incoming triggers or outgoing actions (such as Ethernet or serial communications) then this may have a negative impact on show playback and system responsiveness. If you have any questions about this, please contact support with your project requirements and we'll be happy to advise.
If you need a timeline to run continuously, we'd always recommend setting it to hold at end (rather than loop) where appropriate. A looping timeline requires significantly more processing power because the Controller has to track the time position until released. You should always release timelines when they are not actively affecting output. More information about the differences between loop and hold at end can be found here.
Transparency is a very processor-intensive effect for Controllers to generate. Having one or two layers of transparency on some fixtures will be fine, but having several layers on a fully patched LPC 4 may cause some playback to be choppier than normal.
AVCs don't support timelime pausing, position setting or playback rate changes.